Computer users are increasingly concerned about the security threats posed by viruses, worms, Trojan horses, identity theft, software and media content piracy, and extortion using threats of data destruction. Conventional operating systems provide numerous security features to guard against such attacks. For example, a Trusted Platform Module (TPM) ensures the trustworthiness of software that is run on a computer by submitting trusted measurements of data to the TPM and relying on the TPM to determine if the measurement is what it should be. Computer security is often dependent on being able to predict the behavior of software components. In general, the security of a system may flow from the premise that a known program whose behavior is understood, which proceeds from a known good state, will act in a predictable manner. Conversely, the thwarting of security—which may involve getting a computer system to behave in ways that are outside the contemplation of its designer—can generally be realized by replacing or changing a known program, or running it in a state in which its behavior is not understood. Thus, one aspect of providing security for a computing environment includes verifying that a known program is being used, and that it is proceeding from a known good state. The TPM accomplishes this by validating that data is what it should be because a measurement such as a hash of the data matches a value previously sealed in the TPM.
Most TPMs today conform to the TRUSTED COMPUTING GROUPS® (TCG) standard, entitled “Trusted Platform Module (TPM) Specification Version 1.2” (referred to herein as “TPM specification”). The TPM is a subsystem that may be incorporated into computing platforms to establish trust for the code that is executed by a platform. Standardization of mechanisms for establishing trustworthy code is beneficial because it allows the security and cryptographic community to assess the mechanisms for providing security, and because it promotes customer understanding and trust of new software features. It also encourages innovation in implementing and improving the standard, as contemplated and encouraged by the TCG®.
The TPM specification defines a TPM that provides cryptographic finctions using a cryptographic processor designed to provide trust in the software platform. Since this component is implemented in hardware, it has finite resources. The TCG Trusted Software Stack (TSS) specification defines a software stack that makes use of the TPM resources to provide application-level finctionality that uses the TPM resources to provide trust operations for applications. The TSS allows some sharing of limited TPM resources across multiple applications; however, no provision is made for running a TSS implementation side-by-side with operating system software that may also be using TPM resources. Also, the TSS does not permit multiple operating system instances to be run on a platform, each with its own TSS instances, all of which are running on a single physical TPM.
The TPM has several facilities for supporting access control systems based on software identity. The primary facilities include local software authentication, remote software authentication, and authorized access to local data. Each of these facilities uses PCRs and are thus limited by the PCR's limitations.
In the case of local software authentication, when the TPM is incorporated into a compliant hardware platform, the platform reliably measures and reports the identity of the running software to the TPM. Such authentication may include authentication of low level system software including the BIOS, option ROMs, master boot record, and the like, as well as reliable authentication of an isolation kernel or hypervisor started some time after platform boot. In each case, the TPM and the software platform arrange that the cryptographic hash of the program (e.g., the hypervisor, or operating system loader) is written into a PCR of the TPM. Since programs typically run other programs, a piece of software that has been authenticated might want to “qualify its identity” by changing the PCR to reflect this sort of state change. However, a program should not be able to make unconstrained changes to a PCR value, as this would, for example, allow one operating system, such as Linux, to impersonate another operating system, such as Windows. Accordingly, to securely support changes to the PCRs, PCRs behave like logs to which information is written but may not be removed. To prevent the PCRs from needing unlimited storage, the “log” is typically implemented as a one-way hash function. New information is “hashed into” the PCR, and once it is hashed in it cannot be unhashed because the function is one-way. This function is called “extend” in the TPM specification referenced above. Also, in general, PCRs are only reset when new software is booted. Typically, the TPM has a limited number of PCRs (e.g., 24), only a few of which can be reset under software control.
In the case of remote software authentication, as where a server tests to determine what software is running in different virtual machine (VM) partitions, the TPM contains a key that can be used to “sign” the contents of PCR registers (and other data, to guarantee freshness, associate with the current PCR contents, and the like). The TPM key can be used in cryptographic protocols of the TPM's cryptographic processor to authenticate running software to remote entities. However, for this to work, relying parties have to establish trust in the TPM key. This must be done out of band using, for example, a certificate authority in a process referred to in the TPM specification as “quoting.”
In the case of authorized access to local data, the TPM can protect access to data so that the data is only accessible when the platform (as reflected in the contents of PCR registers) is in an approved state. Because storage on the TPM is limited, this operation is implemented using an authenticated encryption primitive. The TPM specification refers to this process as “sealing.”
Unfortunately, there are several problems with PCRs as implemented in the TPM which limit their use in such TPM facilities. For example, from a software perspective, PCRs are a limited resource. The PCRs that are “for system use” are not limiting if one is booting one operating system; however, if one wishes, for example, to grant TPM access to multiple operating systems running simultaneously in a virtual machine environment, there is the potential that the PCRs will step on each other and cause each other to crash. This problem may even arise in the absence of a virtual machine environment when several applications wish to use PCRs simultaneously. For example, a virus checker may wish to register the hash of the virus definition file, while an audit service may wish to use a PCR to protect logs, while a dozen instances of Common Language Runtime (CLR), a Microsoft software platform that enables developers to write components in multiple languages and have them interoperate, may each wish to hash the assembly they are running into a PCR. The potential for such scenarios may lead to PCR conflict. Also, though a PCR generally provides a one to one mapping of programs to PCRs, when a particular PCR is “quoted,” no mechanism is provided for determining whether the “quoted” PCR was used by the expected program (e.g., the virus checker).
PCRs are further limited in that they are (mostly by design) never reset. This is acceptable for system use (e.g. an audit log), but is more difficult for general application use (e.g. an instance of Microsoft's Internet Information Services (IIS) that wants to protect its logs). Moreover, those PCRs that are resettable generally do not have any interesting policy around when they are reset. Basically, a couple of the TPM's PCRs can be reset by a running hypervisor, while only one PCR can be reset by anyone. This inability to reset most of the PCRs may lead to the proliferation of an error once an error has been introduced.
Thus, despite their extensive use in TPMs, PCRs are limited in number, most are never reset (by design), and those that are resettable do not have any interesting policy concerning when they can be reset and by whom. The invention addresses these limitations in the art.